This invention relates to the field of shared resource data updating and locking mechanisms. In particular, the invention relates to a client locking mechanism for shared resource data updating.
In Web applications, multiple independent users may start working on the same data at the same time. For example, two people may try to reserve the same airline seat at the same time. There is currently no good system to provide a fair outcome to such situations for the end users. The users may spend a lot of time trying to book a non-existing ticket or being unable to book a ticket as another user started the booking process earlier and took a long time to book it. Such systems need a way to determine which person's update/request will be successful.
There are two main existing locking patterns. Firstly, a pessimistic locking pattern, where the first person locks the data while they are updating it. The lock is released when the update is complete. This means that a second person is made to wait until the lock is released; however, when they do get their turn at the lock then they know they have exclusive access to the data.
This style of lock works where there is high contention for data and the changes to data are not very frequent. However, it has the disadvantage that if a first person takes a long time, no one else can access data. The lock is generally given a time-out to enable others to get to the data, this time-out must be set to be long enough for the biggest transaction because once the time-out happens, the first person must start again.
Referring to FIG. 1, a schematic diagram illustrates this method of the prior art referred to as pessimistic locking. A first user (User 1) activity 110 and a second user (User 2) activity 120 are shown on a time-line 130.
As shown in the pessimistic locking of FIG. 1, User 1 110 takes a copy 111 and is able to update 112 their changes successfully before the lock is timed-out 131. User 2 has to wait 121 due to a lock for User 1, and then takes a copy 122. User 2 tries to update 123 but the lock timed-out 131. So User 2 takes another copy 124 which updates 125 successfully before the next time-out 132.
User 2 could only update their changes at the second time. This has made the second user frustrated for the following reasons: User 2 has to wait for a turn to get an access to the data; User 2's first time update is failed due to a lock time-out; User 2 has to take another copy of the data before updating the data; and User 2 may be able to make an update successfully at the second time if User 2 completes in time.
A second locking pattern is an optimistic locking pattern, in which multiple users can take a copy of data at anytime, make changes and then update the data. Whoever updates the data first is successful. This works using timestamps. The timestamp is saved whenever the data is updated. When an update is required, the user takes a copy of the data and the timestamp. When the update is made, the saved timestamp is compared with the copy. If they are the same, the data is saved. If they are different, someone else has changed the data and the user must start it again. This style of locking works well when there are a few updates compared with the number of reads. If there are many updates (for example, in a time of high demand), then there is a lot of contention. A long transaction has little chance of success.
FIG. 2 is a schematic diagram illustrating this method of the prior art referred to as optimistic locking. A first user (User 1) activity 210 and a second user (User 2) activity 220 are shown on a time-line 230.
User 1 210 takes a copy 211, and shortly after User 2 220 also takes a copy 221. The copies have timestamps of the last update. User 1 then updates 212 the data and the timestamp is updated. User 2 then tries to update 222 the data but as the timestamps are different, this fails. User 2 must take a new copy 223 with the updated timestamp and make a further update 224 which this time is successful. User 1 210 may take a further copy 213 for additional updates.
The pessimistic locking might block other people for a long time and the optimistic may require people to rework on the data which they have worked on. Therefore, neither of these methods has provided a good solution for a concurrent environment in Web applications.
Therefore, there is a need in the art to address the aforementioned problems.